Linux Journal January 2015 by Linux Journal

Author:Linux Journal
Language: eng
Format: mobi, epub
Tags: Access Control, Wondershaper, Vagrant, iotop, Kali Linux, Open-AudiT, Pencil2D, Disney, Wireshark, Mozilla, Android App, Multitenant Sites, Permissions, Security, OpenVAS, FreeCAD, Internal Security Review, Servers, Detection, Squid Proxy, DenyHosts, Linux
Publisher: Belltown Media
Published: 2014-12-20T08:00:00+00:00

■ vagrant halt — shuts down the VM.

■ vagrant suspend — pauses the VM.

■ vagrant resume — resumes a paused VM.

■ vagrant destroy — erases the VM (not the Vagrantfile).

Where to Go from Here

I hope that makes the Vagrant workflow clear. If it seems simple enough, but not terribly useful, that’s about all the basics will get you. Although it’s cool to be able to create and destroy VMs so quickly, by itself, the process isn’t very useful. Thankfully, Vagrant bakes in a few other awesome features. I already mentioned the vagrant ssh command that allows you to SSH in to the VM instantly, but that is only the tip of the iceberg.

First, you have the /vagrant folder inside the VM. This is a folder that is mounted automatically inside the running VM, and it points to the project folder itself on the main system. So any files you store in “myfirstvm” alongside the Vagrantfile will be accessible from inside the VM in the /vagrant folder. What makes that useful is that you can destroy the VM, create a new VM, and the files in your project folder won’t be erased. That is convenient if you want to have persistent data that isn’t destroyed when you do a vagrant destroy, but it’s even more useful when you combine it with the scripting capability of the Vagrantfile itself.

Admittedly, it gets a little complicated, but the Vagrantfile can be edited using basic Ruby language to automate the creation and bootup of the VM. Here’s a simple example of an edited Vagrantfile:

# Sample Vagrantfile with startup script

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

config.vm.box = "NAME"

config.vm.provision :shell, path: "startup.sh"

end

The only line I added was the config.vm.provision line. The other lines were created automatically when I initially typed vagrant init. Basically, what the provision statement does is tell Vagrant that once it starts the VM to execute the startup.sh script. Where does it find the startup.sh file? In that shared space, namely the “myfirstvm” folder. So create a file in your myfirstvm folder alongside the Vagrantfile itself called startup.sh:

# This is the startup.sh file called by Vagrantfile

apt-get update

apt-get install -y apache2

Make sure the file is executable:

chmod +x startup.sh

Then, have Vagrant create a new VM. If you haven’t “destroyed” the existing VM, do that, and then type vagrant up to create a new one. This time, you should see the machine get created and booted, but you also should see the system download and install Apache, because it executes the startup.sh file on boot!

That Was the Light-Bulb Moment for Me

Once I understood how Vagrant can call a script when it creates the VM, I started to realize just how powerful and automated Vagrant can be. And truly, that’s just scratching the surface of the things you can do with the Vagrantfile commands. Using that file, you can customize the settings of the VM itself (RAM, CPU and so on); you can create port-forward settings so you can access the Vagrant VM’s ports by connecting to your local system’s

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.